REMARKS 



Claim 1 calls for handling the system- wide state of a wireless device through the host 
controller interface firmware and handling the state of each link with the device through the link 
management firmware. 

The Trost reference is cited but seems to be of very limited pertinency. In fact, the whole 
point of Trost is to migrate host controller interface firmware to hardware. To the extent this is 
done, it goes against what is taught in the present application. 

As explained in the specification at page 4, lines 5-15, the host controller interface 
commands that concern the overall state of the Bluetooth device 10 are processed directly in the 
host controller interface firmware while commands pertaining to each particular link are 
processed in the link manager firmware. The host controller interface firmware keeps track of 
the system- wide state of the link controller of the Bluetooth device 10 while the link manager 
firmware maintains the state of each link. 

As shown in Figure 2 of the present application, during connection establishment, 
communication with hardware, including the processing of any time outs, is handled by the host 
controller interface firmware. After the baseband portion of the connection is established, the 
host controller interface firmware passes control to the link manager firmware for the 
establishment of logical link. 

It is respectfully submitted that the cited reference to Trost is silent about how the state of 
the overall device versus the state of the link are handled. It is simply commensurate with the 
general state of the art described in the present application on page 1. In order to analyze the 
Trost reference, Trost would need to provide information about how a connection is established. 
This he does not do. Trost assumes the connections are already established and never explains 
the establishment of the link. Therefore, it cannot be said how Trost would handle dividing up 
the state of the overall device versus the state of a link. Certainly, to the extent that Trost 
navigates functionality away from the host controller interface firmware to hardware, it seems 
unlikely that Trost could do what is claimed. 

The last office action relies on paragraph 70. That paragraph indicates that the link 
manager is used to negotiate packet types between Bluetooth devices, as well as to set up 
encryption. But this does not go to the question of how the state of a link is monitored. It is also 
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stated that the link manager is also used for setting up SCL links and other link management 
functions. But, again, this too does not go to the management of the state of a link. Paragraph 
70 of Trost also talks about the L2CAP protocol 803 communicating with the host controller 
interface 805, which then communicates with the USB module 807. But, referring to Figure 8, it 
is seen that the element 805 is not firmware, because it is above the dashed line, it is clearly 
hardware. Therefore, this does not go toward what is claimed in the present application. The 
host controller interface firmware is apparently item 81 1, as best as can be determined. But what 
is said about this is that the USB within the Bluetooth device communicates with the host 
controller interface 811 which, in turn, communicates with the physical layer. This provides no 
information about whether the overall state of the Bluetooth device is managed by the host 
controller interface firmware. There is simply too little information to make any conclusion 
other than Trost simply conforms to the standard conventional operation described in the present 
application on page 1 and does not divide up the handling of states as set forth in claim 1 . 
Therefore, reconsideration is respectfully requested. 
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